Creative Process Modeling And Tracking System

ABSTRACT

One embodiment is a system that allows multiple entities to track a process for developing a product. The system receives a process defined in terms of the entities, which are involved in the process, and the relationships, which exist among the entities. The system permits a process instance to be created from the defined process upon deeming that the process is valid, and permits the first process instance to be tracked with respect to requirements and solutions that are specified by entities in the process instance.

FIELD OF THE INVENTION

One embodiment is directed generally to a computer, and in particular toa computerized modeling and tracking system.

BACKGROUND INFORMATION

Generally, a process for creating a product involves a number ofdifferent entities with differing expertise. For example, these entitiesmay include a business team, an engineering team, and a documentationteam. In many cases, one team may outline requirements, which are to besolved by another team. In order to ensure that these requirements aremet, team leaders may meet and provide a “formal handoff.” This formalhandoff may include a number of meetings in which one entity inspectsthe solution, thinks of omissions, and provides feedback to anotherentity.

Such a formal handoff between entities may be error prone, inefficient,and subjective. In addition, changes that may occur during the processmay not be communicated to every team, which may be directly orindirectly affected by such changes. Furthermore, even in the case whereentities have employed a manual cross check between different documentsor components to ensure that the requirements are satisfied, this typeof activity is time consuming, error prone, and difficult to maintain.

SUMMARY

One embodiment is a system that allows multiple entities to track aprocess for developing a product. The system receives a process definedin terms of the entities, which are involved in the process, and therelationships, which exist among the entities. The system determines ifthe process is valid. The system permits a process instance to becreated from the defined process upon deeming that the process is valid,and permits the process instance to be tracked with respect torequirements and solutions that are specified by entities in the processinstance.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system that is configured to implement anembodiment of the present invention.

FIG. 2 is a block diagram illustrating the creative process modeling andtracking system in accordance with one embodiment.

FIG. 3 is a diagram illustrating a process map user interface inaccordance with one embodiment.

FIGS. 4A and 4B illustrate exemplary process maps, which may be createdusing the creative process modeler in accordance with one embodiment.

FIG. 5 is a diagram illustrating a process instance summary userinterface in accordance with one embodiment.

FIG. 6 is a diagram illustrating a user interface to add a new processinstance in accordance with one embodiment.

FIG. 7 is a diagram illustrating a process instance user interface inaccordance with one embodiment.

FIGS. 8A and 8B are diagrams illustrating a user interface to preview arelationship in accordance with one embodiment.

FIGS. 9A and 9B are diagrams illustrating a user interface to view arelationship in accordance with one embodiment.

FIG. 10 is a diagram illustrating a user interface providing a summaryof the components of a selected level in accordance with one embodiment.

FIG. 11 is a diagram illustrating a user interface to create a newcomponent in accordance with one embodiment.

FIG. 12 is a diagram illustrating a user interface to edit a componentin accordance with one embodiment.

FIG. 13 is a flow diagram illustrating a process of creating a processmap in accordance with one embodiment.

FIG. 14 is a flow diagram illustrating a process of defining andtracking a solution, proposed by one level, to a requirement, specifiedby another level, in accordance with one embodiment.

DETAILED DESCRIPTION

One embodiment is a system that enables a user to model the relationbetween all distinct entities involved in a process for creating aproduct, and to track a number of aspects associated with creating aproduct. These aspects may include a state at which a number ofrequirements, specified by one entity, have been solved by components,proposed by another entity.

To aid in the understanding of the present disclosure, a number ofexamples are given with respect to a software process for creating aproduct, such as a software program. However, the present disclosure isnot limited to modeling and tracking software processes, but mayencompass any type of process and/or service, involving multipleentities.

In general, the present disclosure may be relevant to any creativeprocess that includes several steps, which may be managed by differentgroups and/or which may be based upon different roles. To illustrate,the present disclosure may be applied, for example, to a processrelating to the creation of consumer electronic products. Typically,such a process may involve business strategists to set high levelrequirements, and a group of individuals to implement thoserequirements. The group of individuals may include a software team, afirmware team, a hardware team, and a design team.

As discussed, the present disclosure may be applicable to a variety ofprocesses. To further illustrate, other non-limiting examples mayinclude a process for constructing a home or a process for drafting apatent application.

FIG. 1 is a block diagram of a system 10 that can implement anembodiment. System 10 includes a bus 12 or other communication mechanismfor communicating information, and a processor 22 coupled to bus 12 forprocessing information. Processor 22 may be any type of general orspecific purpose processor. System 10 further includes a memory 14 forstoring information and instructions to be executed by processor 22.Memory 14 can be comprised of any combination of random access memory(“RAM”), read only memory (“ROM”), static storage such as a magnetic oroptical disk, or any other type of computer readable media. System 10further includes a communication device 20, such as a network interfacecard, to provide access to a network. A user may interface with system10 directly, or remotely through a network or any other method. Databasesystem 30, coupled to bus 12, is used to store data for various modules.

Computer readable media may be any available media that can be accessedby processor 22 and includes both volatile and nonvolatile media,removable and non-removable media, and communication media.Communication media may include computer readable instructions, datastructures, program modules or other data in a modulated data signalsuch as a carrier wave or other transport mechanism and includes anyinformation delivery media.

Processor 22 is further coupled via bus 12 to a display 24, such as aLiquid Crystal Display (“LCD”), for displaying information to a user. Akeyboard 26 and a cursor control device 28, such as a computer mouse, isfurther coupled to bus 12 to enable a user to interface with system 10.

In one embodiment, memory 14 stores software modules that providefunctionality when executed by processor 22. Modules include anoperating system 42 that provides operating system functionality forsystem 10. Modules further include a creative process modeling andtracking system 44 (“system 44”), which is enabled to model and track acreative process, as disclosed in more detail below. Modules may includeother functional modules 46, which may integrate or interact with system44. As an example, functional module 46 may include a documentmanagement system (“DMS”). The DMS may store and version components.

Functional module 46 may include project management software. Projectmanagement software may include timeline information extracted from aproject plan held in external project management software for theproduct being created. This timeline information may be used to generatealerts and/or notifications in cases, where at least one of an entity'srequirements is not completely solved as a deadline for the entity inquestion approaches.

For example, when functional module 46 includes project managementsoftware, this may allow a component to be linked to a line item in aproject plan. To illustrate, component #3 (“Add Appointment Dialog” ofthe Functional Specification level) of FIG. 7 may be linked to an itemin a project plan. Once this link has been established, system 44 may beable to utilize and communicate information, such as the start/stoptimes of an activity or the estimated duration of an activity. Thisinformation (e.g., estimated duration of line items in the project planthat are linked to a component) may be used to derive a total amount oftime that the project plan may spend on one level or on a single product(i.e., all levels). The total amount of time may be included in one ofthe UIs (e.g., process instance UI 250) of creative process tracker 220.

Functional module 46 may include communications, collaboration, and/orsocial networking software. These types of software may facilitate orallow an entity to instant message, email, telephone, check theavailability of, and/or schedule meetings with the resource in question,since system 44 involves working with multiple entities to agree onwhether certain components are deemed to be valid and full solutions tothe requirements. In other embodiments, creative process modeling andtracking system 44 may be a stand-alone system, or may be part of anyother system.

FIG. 2 is a block diagram of a creative process modeling and trackingsystem 44 in accordance with one embodiment. Creative process modelingand tracking system 44 (“system 44”) includes creative process modeler210 and creative process tracker 220.

Creative process modeler 210 allows an entity, such as a user, to definea process associated with producing and/or developing a product.Creative process modeler 210 includes a module that enables a user todefine a creative process. This module may include a process map userinterface 212 (“process map UI 212”).

Creative process tracker 220 allows an entity to create instances of aproduct and track the creation of the product through all levels of acreative process, defined, for example, by a process map. Creativeprocess tracker 220 provides an entity with the ability to check thatall of the demands of one level have been satisfied by another level.Creative process tracker 220 allows a number of changes to be made tothe content of any level, and provides instant feedback regarding theupstream and downstream consequences of those changes.

Creative process tracker 220 may be implemented using a number ofmodules and/or sub-components, such as a process instance summary userinterface 230 (“process instance summary UI 230”), a new processinstance user interface 240 (“new process instance UI 240”), a processinstance user interface 250 (“process instance UI 250”), a preview userinterface (“preview UI 252”), a view relationship user interface (“viewrelationship UI 254”), components user interfaces 260 (“components UIs260”), a component change detection module 270, a recertificationnotification module 280, and scenario analysis tools 290. Each of thesemodules is described in more detail below.

Although creative process modeling and tracking system 44 may include anumber of distinct modules, as illustrated in FIG. 2, it should berecognized that some modules may be combined, and/or some functions maybe performed by one or more modules. Therefore, the embodiment of FIG. 2represents the major components of creative process modeling andtracking system 44, but these components may be combined or divideddepending on the particular design.

FIG. 3 is a diagram illustrating a process map UI 212 of the creativeprocess modeler 210 of FIG. 2 in accordance with one embodiment. Processmap UI 212 includes a process map development area 302, which may beused to define a process, involved in creating a product. In oneembodiment, a process may be defined in terms of a process map 312.

A process map provides a visual representation of the levels, which areinvolved in a process, and any relationships that may exist between thelevels. A level, generally, refers to an entity that is responsible fora particular aspect of the overall product, and has distinctrequirements and/or distinct solutions. In process map 312, a level mayinclude an entity, represented by an entity name 308 and a general role310. In addition, process map 312 may specify the roles of users, whobelong to those levels. Roles may be defined through a security systemthat restricts access to authorized users, such as Role Based AccessControl (“RBAC”) system.

In one embodiment, process map UI 212 allows a user to create a level byselecting and/or dragging a new process level 318 into the process mapdevelopment area 302. In addition, process map UI 212 allows a user tospecify an entity and/or role for the level. This may be performed byselecting the level 304, and then entering the information into thegraphical representation of the level 304 itself, or entering theinformation into editor 324.

A relationship, generally, refers to a known association or relationamong entities. In process map 312, a relationship may be defined, forexample, by connecting levels. Arrow 306 may represent the nature of therelationship, which exists between levels. A level, where an arroworiginates, is considered to be a “prior level” to the level, where thearrow enters. Generally, a “prior level” is responsible for setting therequirements, which a “subsequent level” is responsible for solving. Thesubsequent level may provide the actual solution to a requirement.Additionally or alternatively, the subsequent level may solve arequirement, for example, by delegating some of the responsibility to atleast one other level, or by restating at least one of the requirementsfor another level to solve.

As an example, FIG. 3 illustrates a process map 312, named “StandardSoftware Development Process” 322, which has been created in thecreative process development area 302. As indicated by the process mapname 322, process map 312 defines a process associated with creating aparticular piece of software. Process map 312 includes the followinglevels: Business Requirements level, Functional Specification level,User Guide level, and Technical Design level. As defined by process map312, Business Requirements level includes a Business Strategist role;Functional Specification includes a Functional Analyst role; User Guideincludes a Technical Writer role; and Technical design includes aTechnical Architect role. Process map 312 indicates that FunctionalSpecification level is currently selected, and its properties aredisplayed in the editor 324. Process map 312 defines a process in whichthe Business Requirements level may specify a number of requirements forthe Functional Specification level to solve, while the FunctionalSpecification level may specify a number of requirements for the UserGuide and the Technical Design, respectively, to solve.

Creative process modeler 210 allows a user to create a number ofdifferent process maps. Selecting option 316 allows a user to create anew process map. A user may save the current process development area302 at any point in time by selecting save option 314.

Once a process map has been saved, creative process modeler 210 allows auser to be able modify the process at a later time, or to create a newprocess from the saved process by using the saved process as a template.

FIGS. 4A and 4B illustrate exemplary process maps that have been createdvia the creative process modeler 210. FIG. 4A illustrates a process map410, named “Software Process I,” which includes a Business Requirementslevel 412, a Functional Design level 414, a Technical Design level 416,and a Construct level 418. FIG. 4B illustrates a process map 420, named“Software Process II,” which includes substantially the same levels(e.g., Business Requirements level 422, Functional Design level 424,Technical Design level 426, Construct level 428) as Software Process I,but also includes a Product Documentation level 430 and an Inline Helplevel 432.

In this example, the process map author used Software Process I, as astarting template to create a new process map, Software Process II.Alternatively, the process map author may create Software Process IIwithout using Software Process I, as a starting template. SoftwareProcess II is defined as a software development process that is similarto the process outlined in Software Process I, but further includes aProduct Documentation level 430 and an Inline Help level 432. Accordingto the Software Process II map, Product Documentation 430 must coversubstantially all of the requirements detailed in Functional Design 424,while In-line Help 432 must cover substantially all of the requirementsproduced in Construct 428.

As illustrated by the exemplary maps discussed above, creative processmodeler 210 allows a user to define a creative process in terms of theentities and relationships involved in creating a particular product.Creative process modeler 210 allows a user to define processes,possessing different gradients of simplicity or complexity.

Once a process for developing a product is established via creativeprocess modeler 210, this same process may be utilized in developing anumber of software instances and/or products, which involve the samelevels and relationships. In addition, a user may track these instancesusing creative process tracker 220.

FIG. 5 is a diagram illustrating a process instance summary UI 230 inaccordance with one embodiment. Process instance summary UI 230 displaysa number of process instances, and provides an overall status report foreach process instance. Process instance summary UI 230 provides a quickreference, indicating whether the current overall status of a giveninstance, which is being tracked, is deemed to be completely solved withrespect to all requirements according to all of the entities involved inthe process.

Process instance summary UI 230 displays a number of process instances,which may be tracked. Each process instance may be referenced by aprocess name 502. Process name 502 may include a hyperlink 508.Hyperlink 508 provides direct access to a process instance screen, asshown in FIG. 7. A status 504 is provided for each creative processinstance 502. Status 504 indicates the degree to which all levels of aparticular process are solved. Process instance summary UI 230 mayindicate which creative process model (or process map) is being used foreach process instance in a corresponding process type 506 field.

A new process instance may be added by activating an “Add New ProcessInstance” button 510 on the process instance summary UI 230. The “AddNew Process Instance” button 510 provides access to UI 240 of FIG. 6 toadd a new process instance.

FIG. 6 is a diagram illustrating a user interface to add a new processinstance in accordance with one embodiment. UI 240 includes a field inwhich a user may input a process instance name 602 to identify the newprocess instance. UI 240 includes a field for the user to select aprocess type 604 for the new process instance. In general, process type604 refers to a particular process, which has been defined, for example,as a process map via creative process modeler 210. Process type field604 provides a user with an opportunity to select an existing process,or to create a new process. When the user selects an existing processtype (e.g., “Standard Software Development Process” of FIG. 3), then UI240 displays each defined level 606 of the selected process type inconjunction with its corresponding assigned role 608. UI 240 provides anentity with an opportunity to assign or specify resources 610 for eachdefined level 606 of the selected process type 604. Resources 610indicate the entities that are responsible for each defined level 606and role 608. Resource 610 may include a single entity, or a number ofentities. As an example, the Business Requirements level includes asingle entity (e.g., Samuel Plover) as a resource 610, while theFunctional Specification level includes multiple entities (e.g., RobFlintlock and Samantha Marland) as a resource 610.

Alternatively, if a user wishes to create a new process type, then theuser will select “New” from the process type menu 604. Selecting “New”will direct a user to the process map UI 212, shown in FIG. 3, so thatthe user may define a new process.

UI 240 of FIG. 6 includes a cancel option 614, which may be selected anytime. Cancel option 614 cancels the user's current attempt to create anew process instance in UI 240. In one embodiment, activating the “AddNew Process Instance” button 510 of the process instance summary UI 230may be the main way or only way to navigate to UI 240. Thus, acancellation of an attempt to create a new process instance via canceloption 614 directs the user back to the process instance summary UI 230.

UI 240 of FIG. 6 includes option 612, which allows a user to submit anew process instance into the system. A user is able to incorporate theinformation from UI 240 into system 44 to create a new process instanceby activating the “done” option 612. Creative process tracker 220 thendirects the user to an updated process instance summary UI 230. Processinstance summary UI 230 is updated to include the newly added process.Details of the newly added process may be obtained by clicking on ahyperlink 508 associated with a process name 502, which will providedirect access to a process instance UI 250, as shown in FIG. 7.

FIG. 7 illustrates a diagram of a process instance UI 250 in accordancewith one embodiment. Process instance UI 250 provides a user withrelevant information concerning a selected process instance. Withprocess instance UI 250, a user can view the overall process, and trackthe creation of the product with respect to any set of levels of theprocess. In this example, process instance UI 250 displays a processinstance of “Calendar Software,” which is the first listed processinstance shown in process instance summary UI 230 of FIG. 5.

Process instance UI 250 includes an overview region 710 and a detailregion 720. Overview region 710 provides a general overview of aselected process instance. Overview region 710 includes a status map712, corresponding to the selected process instance. Status map 712 is aprocess map that indicates a current overall status of each level of theselected process instance. Status map 712 may indicate the assignedresources, as defined, for example, in UI 240.

In FIG. 7, status map 712 indicates a status of each level by using acolor-coded scheme. Overview region 710 may include a status key 714,which provides the details of the status indication scheme (e.g., colorcoded scheme) so that a user may easily glean the status from status map712. In this example, a level may include one of the following statuses:“Level is Not Solved by Subsequent Levels,” “Level is Partially Solvedby Subsequent Levels,” “Level is Completely Solved by SubsequentLevels,” or “No Subsequent Levels.”

Detail region 720 becomes populated with data when a number of adjacentlevels are selected from overview region 710. In most cases, twoadjacent levels are selected. In the example shown in FIG. 7, theBusiness Requirements level and the Functional Specification level havebeen selected.

Detail region 720 includes a component section 730. Component section730 is populated with a table for each level that is selected. In thiscase, two levels have been selected, and thus component region 730includes two side-by-side tables 732, 734. Typically, component region730 displays a table 732, associated with the prior level, to the leftof a table 734, associated with the subsequent level. Table 732 displaysa list of components, associated with one of the selected levels (e.g.Business Requirements level). Table 734 displays a list of components,associated with the other selected level (e.g., Functional Specificationlevel).

In one embodiment, the list of components, shown in table 732, is acomprehensive listing of all of the components of the first selectedlevel. In addition, the list of components, shown in table 734, is acomprehensive listing of all of the components of the second selectedlevel. The comprehensive listing includes all active components that arecreated for a level.

Other embodiments may be configured such that the list of components isa subset of the comprehensive listing of all components for the selectedlevel. For example, in another embodiment, the list of components, shownin table 732, may be configured to display all components of the firstselected level that are requirements and/or solutions for the secondselected level. Likewise, the list of components, shown in table 734,may be configured to display all components of the second selected levelthat are requirements and/or solutions for the first selected level.

As shown in tables 732, 734, each level may include a number of distinctcomponents. In general, anything that contributes to a description of aparticular level may be considered a component of that level. Forexample, a particular level may include solutions embodied by anelectronic document, and the components of this level may includesections of the electronic document.

Tables 732, 734 include a component number followed by a component name.Each component may be associated with a component author. Components areowned/authored by an entity, such as assigned resource 610. Severalauthors may contribute to components of a given level. By allowingcollaboration, creative process tracker 220 is able to accommodate anumber of different working environments, scenarios, and/or situations.For example, a Functional Design may be solved by a Technical Designinvolving multiple Technical Design Documents, each authored/owned by aseparate entity. In such a case, each Technical Design may be defined bya group of components, which contribute to a complete solution providedby the Technical Design level.

Components may be edited by their respective component owners/authors.To edit a component, the user selects the edit components button 738a/738 b, corresponding to the level of the component to be edited. Editcomponents button 738 a allows the user to edit a component within thefirst selected level corresponding to table 732. Edit components button738 b allows the user to edit a component within the second selectedlevel corresponding to table 734. When an edit components button (e.g.,738 a or 738 b) is selected, system 44 directs the user to a userinterface, as shown in FIG. 10, in which the user may choose a componentto be edited from a set of components, associated with the selectedlevel.

Detail region 720 includes a relationship proposal section 740, whichallows users to propose relationships between selected components of theselected levels. Specifically, relationship proposal area 740 allows aproposer to indicate if a proposed relationship between selectedcomponents, associated with the selected levels, is a “Full Solution” ora “Partial Solution.”

System 44 defines these relationship types as follows:

Full Solution: A set of components from one level completely solves aset of components of another level; and

Partial Solution: A set of components from one level partially solves aset of components of another level.

To propose a new relationship, a proposer selects at least one componentfrom each level. Selections can be made by clicking on a checkbox 736,corresponding to the component to be selected. As an example, whenrelationship #3, shown in relationship table 752, was created, RobFlintlock selected a checkbox 736 for Business Requirement component #4(“Navigate to any Date”) from table 732 and selected a checkbox 736 forFunctional Specification Requirement component #1 (“Calendar NavigationWidget”) from table 734. Rob Flintlock then proposed that the “CalendarNavigation Widget” provides a full solution to the business requirement,associated with being able to “Navigate to any Date.”

Creative process tracker 220 may apply restrictions such that onlycertain entities are able to propose relationships. For example,creative process tracker 220 may permit only component authors, involvedin the relationship, to have the authority to propose a relationship. Inthe example shown in FIG. 7, creative process tracker 220 is configuredsuch that only the Functional Analyst (e.g., “Rob Flintlock”) is able toauthor a relationship proposing that a Business Requirement component issolved (e.g., “Full Solution”) by a set of components in the FunctionalDesign. In the default setting, the current user of the system 44 isspecified as the proposer.

In one embodiment, system 44 may employ a RBAC system. System 44 may beconfigured such that only certain users are authorized to performcertain functions (e.g., proposing a relationship, accepting arelationship, and etc.) based on a number of factors, such as theirassigned roles, their corresponding level, and whether they authored orcontributed to the component. System 44 may allow for certain rules andrestrictions to be employed in accordance with users' preferences andobjectives.

Process instance UI 250 allows the proposer to preview the relationshipbefore formally submitting it into system 44 by selecting a previewoption 744. Preview option 744 provides direct access to a UI that showsthe actual contents of each of the components in the proposedrelationship. In one embodiment, preview option 744 may provide directaccess to a preview UI, as shown in FIGS. 8A and 8B. This preview UIprovides a user with an opportunity to verify that the correctcomponents have been selected and/or that the relationship isappropriately characterized. If the proposer would like to change one ofhis/her selections, then the proposer simply un-checks the incorrectselection from checkbox 736 and checks the appropriate selection oncheckbox 736. When a new relationship is ready to be submitted, proposeractivates a command button to create the proposed relationship 746.

Detail section 720 includes a relationship tracker 750. Relationshiptracker 750 provides an entity with the ability to track anyrelationship, which has been submitted between components of theselected levels.

Once a relationship, associated with the selected levels, has beenauthored, the relationship is entered into a relationship table 752 andassigned a unique relationship number 756. Relationship number 756uniquely identifies a particular relationship, defined by at least onecomponent (e.g., a requirement) of one level, and at least one component(e.g., a solution to the requirement) of another level.

Relationship table 752 may include a mapping that indicates arelationship between at least one component of one level and at leastone component of another level. For example, the mapping may include alisting of at least one component of the first selected level and alisting of at least one component of the second selected level. In FIG.7, relationship table 752 includes a “Business Requirement Components”column and a “Functional Specification Components” column. In thisinstance, each component is identified by its component number. Forexample, component #1 (“Ability to add an appointment”) of the businessrequirement level maps to components #1 (“Calendar Navigation Widget”),#2 (“Daily Calendar Screen”), and #3 (“Add Appointment Dialog”) of theFunctional Specification level. In other words, on Jan. 1, 2008,Samantha Marland proposed that components #1, 2, and 3 of the FunctionalSpecification level represent a full solution to component #1 of theBusiness Requirement level. Additionally or alternatively, other mappingtechniques may be utilized to illustrate the relationship betweencomponents of one level with respect to components of another level.

Relationship table 752 includes the current relationship type of eachunique relationship. Relationship table 752 includes a status of eachunique relationship. The status describes the current state of a definedrelationship between at least one component of one level and at leastone component of another level. For example, the status may indicate ifa relationship is in a proposed state, an accepted state, or a rejectedstate. In the event that at least one component in a relationship hasbeen modified, the status will be updated to indicate that a componenthas been modified (e.g., status=“Proposed Components Modified)”). In theevent that a component in an accepted relationship has been modified,the status in the relationship table 752 will be reverted from anaccepted state to a proposed state (i.e., from status=“Accepted” tostatus=“Proposed (Components Modified)”).

Relationship table 752 includes a proposer and a proposal date for eachunique relationship. Proposer indicates the entity that created orproposed the unique relationship. Proposal date indicates the date thata unique relationship was created.

In the event that a relationship is modified or a component is modifiedin a manner that affects the proposed relationship, then therelationship table 752 would be updated to reflect the modification. Forexample, if Rob Flintlock proposed a relationship and Samantha Marlandlater modified a component in that relationship, then the relationshiptable 752 would be updated. In this instance, the proposer would changefrom “Rob Flintlock” to “Samantha Marland.” In addition, the proposaldate would change from Rob Flintlock's proposal date to the date thatSamantha Marland's modification was made. Additionally or alternatively,system 44 may include a relationship log that provides a full history ofthe relationship and tracks all related changes. For example,relationship log may include a record of the original proposer andoriginal proposal date. In addition, relationship log may include arecord of each subsequent modification date (e.g., timestamp), as wellas the user that modified the components and/or relationships. Therelationship log may include other relevant data and links regarding therelationship, as well as the components involved in the relationship.

Relationship table 752 includes an acceptor and an acceptance date foreach unique relationship. An acceptor, generally, refers to an entitythat is authorized to determine and accept a relationship as being a“partial solution” or a “full solution” in response to the relationshipproposed by the proposer. In many cases, the component owner of theprior level, who had set forth the component requirements, is theauthorized entity and the designated acceptor. An accepted state, ingeneral, refers to an acceptor's acquiescence with the proposer'sproposition that at least one component of a level adequately andsufficiently meets the requirements of at least one component of anotherlevel. Acceptance date indicates the date that the acceptor accepted theproposed relationship.

In the event that at least one component in an accepted relationship hasbeen modified, the acceptor and the acceptance date may be deleted fromrelationship table 752 to indicate that the relationship has to bereviewed and accepted in view of the modified component. In oneembodiment, system 44 may include a relationship log that includes arecord of each acceptor and acceptance date in accordance with eachmodification. The relationship log is configured to provide a user withthe ability to obtain relevant data regarding the history of arelationship, as well as any changes thereto.

Relationship table 752 includes a checkbox 754 in association with eachunique relationship, which has been proposed and entered into system 44.Checkbox 754, when marked, may be used to select a relationship fordeleting, viewing, accepting, or rejecting.

In FIG. 7, relationships may be modified indirectly. For example, arelationship may be modified by modifying at least one of the components(e.g., requirements and/or solutions) of the relationship. Arelationship may also be modified by creating a new relationship anddeleting, if necessary, the existing relationship. In one embodiment,system 44 may be enhanced to allow for relationships to be modified viaan edit relationship button and an edit relationship user interface.

Relationship tracker 750 includes a delete relationship button 758,which allows an authorized entity to delete a relationship. In oneembodiment, creative process tracker 220 may only allow relationships tobe deleted by their corresponding proposers.

As discussed above, a relationship log may be maintained by system 44.When a relationship is deleted, the relationship log may indicate thatthe relationship has been deleted. This information may include adeletion timestamp, the user that deleted the relationship, thecomponents of the relationship, and other relevant information. Inaddition, the relationship log (or a related user interface) may permitan authorized user (e.g., a relationship proposer) to undelete orreactivate a relationship in certain instances.

Relationship tracker 750 includes a view relationship button 760. Whenactivated, view relationship button 760 provides direct access to acomponent UI, which shows the actual content of each of the componentsinvolved in a selected relationship. In one embodiment, the viewrelationship button 760 may provide direct access to UI 254, as shown inFIGS. 9A and 9B.

Relationship tracker 750 includes an accept button 762, which enables anacceptor to accept a proposed or modified relationship. In oneembodiment, creative process tracker 220 may authorize this acceptingfunctionality to only the appropriate component owners. In many cases,the appropriate component owner is a component author, who providescomponent requirements for an input level and seeks component solutionsfrom another level.

Relationship tracker 750 includes a reject relationship(s) button 764.The rejection relationship(s) button 764 may be used to indicate that arelationship has been reviewed, but has not been accepted by theappropriate component owner.

FIGS. 8A and 8B illustrate a user interface that allows a user topreview a relationship in accordance with one embodiment.

Preview UI 252 includes information 810 regarding the relationship. Forexample, information 810 may indicate the levels, which are involved inthe relationship. In FIGS. 8A and 8B, information 810 includes thefollowing message: “You are proposing a relationship between theBusiness Requirements Level and the Functional Specification Level.”Information 810 is configured to specify the appropriate levels thatcorrespond to the components, which have been selected for therelationship.

Preview UI 252 displays the components that define the relationship. Forexample, preview UI 252 includes a component solution section 820 and acomponent requirement section 830. Component solution section 820 isconfigured to include at least one component. As shown in FIGS. 8A and8B, a component solution may be identified by its component name (e.g.,“Add Appointment Dialog”), component number (e.g., “#3), and componentauthor (e.g., “Samantha Marland”).

Each component in the component solution section 820 may include ahyperlink (e.g., component name) that allows a user to view the actualcontents of the component. The link may provide the content in a formthat is suitable for the content type. For example, the link may provideaccess to a web browser that shows the component content (e.g., adocument, a pdf, an image, an audio file, and etc.). Each component mayinclude component details 822. Component details 822 may includeinformation, such as a corresponding component description. Componentdetails 822 may be a feature, which is collapsible and expandable. Forexample, FIG. 8A displays the component details 822 in collapsed form,while FIG. 8B displays the component details 822 in expanded form.

Similarly, component requirement section 830 is configured to include atleast one component. As shown in FIGS. 8A and 8B, a componentrequirement may be identified by its component name (e.g., “Ability toadd an appointment”), component number (e.g., “#1), and component author(e.g., “Samuel Plover”).

Each component in the component requirement section 830 may include ahyperlink (e.g., component name) that allows a user to view the actualcomponent and its contents. The link may provide the content in a formthat is suitable for the content type. For example, the link may provideaccess to a web browser that shows the component content (e.g., adocument, a pdf, an image, an audio file, and etc.). Each component mayinclude component details 832. Component details 832 may includeinformation, such as a corresponding component description. Componentdetails 832 may be a feature, which is collapsible and expandable. Forexample, FIG. 8A displays the component details 832 in collapsed form,while FIG. 8B displays the component details 832 in expanded form.

Preview UI 252 may include any relevant information regarding therelationship and/or any relevant information regarding the componentsinvolved in the relationship. For example, preview UI 252 may furtherinclude a relationship type field.

Preview UI 252 may include a button 840 (e.g., “Done” button) thatdirects the user to corresponding process instance UI 250.

FIGS. 9A and 9B illustrate a user interface that allows a user to view aproposed relationship, which has been established, in accordance withone embodiment.

View relationship UI 254 includes information 910 regarding therelationship. For example, information 910 may indicate the levels,which are involved in the relationship. In FIGS. 9A and 9B, information910 includes the following message: “You are proposing a relationshipbetween the Business Requirements Level and the Functional SpecificationLevel.” Information 910 is configured to specify the appropriate levelsthat correspond to the components, which have been selected for therelationship.

View relationship UI 254 may include additional information 912regarding the relationship. For example, additional information 912 mayinclude the relationship type, the status, proposal information, andacceptance information. In FIGS. 9A and 9B, the additional information912 indicates that the relationship, proposed by Samantha Marland on May23, 2008, is a full solution, which has been accepted by Samuel Ploveron May 24, 2008.

View relationship UI 254 displays the components that define therelationship. For example, view relationship UI 254 includes a componentsolution section 920 and a component requirement section 930. Componentsolution section 920 is configured to include at least one component. Asshown in FIGS. 9A and 9B, each component in component solution section920 may be identified by its component name (e.g., “Add AppointmentDialog”), component number (e.g., “#3), and component author (e.g.,“Samantha Marland”).

Each component in the component solution section 920 may include ahyperlink (e.g., component name) that allows a user to view the actualcontents of the component. The link may provide the content in a formthat is suitable for the content type. For example, the link may provideaccess to a web browser that shows the content (e.g., a document, a pdf,an image, an audio file, and etc.). Each component may include componentdetails 922. Component details 922 may include information, such as acorresponding component description. Component details 922 may be afeature, which is collapsible and expandable. For example, FIG. 9Adisplays the component details 922 in collapsed form, while FIG. 9Bdisplays the component details 922 in expanded form.

Similarly, component requirement section 930 is configured to include atleast one component. As shown in FIGS. 9A and 9B, the componentrequirement may be identified by its component name (e.g., “Ability toadd an appointment”), component number (e.g., “#1), and component author(e.g., “Samuel Plover”).

Each component in the component requirement section 930 may include ahyperlink (e.g., component name) that allows a user to view the actualcomponent and its contents. The link may provide the content in a formthat is suitable for the content type. For example, the link may provideaccess to a web browser that shows the component content (e.g., adocument, a pdf, an image, an audio file, and etc.). Each component mayinclude component details 932. Component details 932 may includeinformation, such as a corresponding component description. Componentdetails 932 may be a feature, which is collapsible and expandable. Forexample, FIG. 9A displays the component details 932 in collapsed form,while FIG. 9B displays the component details 932 in expanded form.

In this particular case, FIGS. 9A and 9B display an instance in which auser is viewing relationship #1 at a later date than when processinstance UI 250, which is shown in FIG. 7, was viewed. This is madeevident by additional information 912, as well as component solutionsection 920 and component requirement section 930. In the earlierinstance, relationship #1 was proposed on Jan. 1, 2008 and defined bycomponent #1 of the Business Requirement level and components #1, 2, and3 of the Functional Specification level, as shown in relationshipsection 750 of FIG. 7. In the later instance, relationship #1 wasre-proposed on May 23, 2008, as shown in FIGS. 9A and 9B. In this laterinstance, relationship #1 is defined by component #1 of the BusinessRequirement level and components #3 of the Functional Specificationlevel. As shown in FIGS. 9A and 9B, the relationship proposer (e.g.,“Samantha Marland”) modified relationship #1 to provide component #3 ofthe Functional Specification level as the only component solution tocomponent #1 of the Business Requirement level. In this case, SamanthaMarland may have deleted components #1 and #2 from proposed relationship#1 of Jan. 1, 2008.

View relationship UI 254 may include a button 940 (e.g., “Done” button)that directs a user to corresponding process instance UI 250.

FIGS. 10-12 illustrate a number of component UIs 260 that may beassociated with system 44. Component UIs 260 provide a user with theability to view components, create new components, modify existingcomponents, and delete components.

Components may be defined inline or reference a set of external sources,or be a mixture thereof. For example, if the component is simply plaintext, component UIs provide some facility for entering text directlyinto the component UIs. If the component is a section of a document, awhole web page, or a fragment of a web page, then a component UI may beimplemented such that an entity may select a link or reference to thatexternally defined object. If the component content cannot be enteredinto the component UI and is not easily referenced, the component UI maybe implemented such that an entity may note a label for the component.As an example, an entity may enter the label, “Section 5 of theFunctional Specification,” in the event that the entity cannot enter orprovide a link for the component content. Although it is recognized thata component may include an internal or external source, FIGS. 11-12illustrate a simplified example in which text describing the componentis entered into the component UI.

FIG. 10 is a diagram illustrating a UI 1000, providing a summary of thecomponents of a level in accordance with one embodiment. UI 1000 allowsan entity to view all of the components of a selected level. An entitymay navigate to UI 1000 by selecting the edit components option 738 ofFIG. 7, corresponding to one of the selected levels. Additionally oralternatively, an entity may navigate to UI 1000 by selecting (e.g.,double clicking) a level from status map 712 via process instance UI250. Each component 1004 may include a hyperlink, which may direct theuser to UI 1200 of FIG. 12.

In association with each component 1004, UI 1000 displays the uniquecomponent number 1002, the component version number 1006, the componentowner 1008, and the component status 1010. In this instance, componentstatus 1010 is a combination of the relationship status and therelationship type.

As discussed, in one embodiment, UI 1000 displays a comprehensivelisting of all of the components of a selected level. In the exampleshown in FIG. 10, UI 1000 illustrates a component summary of theBusiness Requirements Level. Since Samuel Plover is the assignedresource of the Business Requirements Level, Samuel Plover is listed asthe component owner for each listed component of this level. Inaddition, in this example, UI 1000 illustrates that componentrequirements #2 and #4 have been completed (“Accepted Solved”).Component #3 indicates a “Not Solved” status, which means that nosolution has been proposed for creating a weekly calendar view.

As another example, if the Functional Specification level was selectedto be displayed in UI 1000, then UI 1000 would display a comprehensivelisting of all of the components of the Functional Specification. Thecomprehensive listing of the components for the Functional Specificationmay include all components solutions for the Business Requirement level,as well as all component requirements for the User Guide level and theTechnical Design level.

UI 1000 includes a button 1012, which allows a user to navigate to UI1100, shown in FIG. 11, to create a new component.

FIG. 11 is a diagram illustrating a UI 1100 to create a new component inaccordance with one embodiment. UI 1100 includes a field for an entityto specify a component name 1102, which identifies the component and/orits function. UI 1100 may also require the user to submit acorresponding component description 1108 that further describes thecomponent, a requirement of the component, or the component'sfunction/solution. Although UI 1100 discloses an example in which thecomponent is defined by a component description, the component may bedefined inline or reference a set of external sources, as discussedabove.

System 44 automatically assigns a unique component number 1104 to thenew component, which will be created upon activating a create button1110. The unique component number 1104 may be used throughout system 44when referring to the component, as illustrated, for example, in FIGS.7-12. UI 1100 displays this unique component number 1104 in associationwith the component. UI 1100 may further indicate the version number 1106of the component. Version number 1106 indicates if the component hasundergone any revisions, as well as the number of times that it has beenmodified. In the default setting, when creating a new component via UI1100, system 44 assumes that it is the first version and that thecomponent owner/author is the current user of the system 44.Additionally or alternatively, when creating the component, UI 1100 maypermit the user to specify the component owner or the component authorof the particular component being created.

As an example, FIG. 11 illustrates the creation of component #6. In thiscase, Samuel Plover is the current user of system 44 and the authorizedcomponent author because he owns the Business Requirements Level. SamuelPlover decides that the Calendar Software needs to be able to allowusers to see each other's calendars in certain instances. Therefore,Samuel Plover creates a component named, “View the calendar of anotheruser.” System 44 assigns a unique component number to the component. Inthis case, the unique component #6 is assigned because five othercomponents have already been created in the Business Requirements level(FIG. 7). In addition, since this component does not refer to a previousversion, UI 1100 indicates that this component is the first version. UI1100 also provides the user with a field to input a componentdescription. In this case, Samuel Plover enters the following componentdescription: “When a user wishes to create an appointment, the user mayneed to understand the availability of other users. Therefore the userneeds to be able to see other user's calendars.”

Once the component name and the component description have been entered,the user may integrate the new component into the system. For example,this newly created component may be entered into the system uponactivating a create button 1110, provided on UI 1100. System 44 storesthe date that the first version was created and updates the BusinessRequirements Level to include component #6 in every appropriateinstance. System 44 allows the component author and any authorizedindividual to edit a component after it has been created.

FIG. 12 is a diagram of a UI 1200 to edit a component in accordance withone embodiment. A user may navigate to UI 1200 by selecting and/oractivating a hyperlink, which corresponds to a particular component 1004of UI 1000. UI 1200 provides an editing window 1210, a component historywindow 1220, and a relationship tracking window 1230 so that the usermay view and assess the impact of any modifications that may be madeduring the component editing process.

Editing window 1210 permits a component author or authorized entity tomodify the component and save it as a new version. The layout of theediting window 1210 may be similar to the layout of UI 1100 to create anew component (FIG. 11). Editing window 1210 includes a copy of aselected version of the component that is to be modified. In many cases,the most recent version of the component is the selected version.

Component history window 1220 provides a listing of a set of versions ofthe selected component. In the default setting, component history window1220 provides a complete listing of all versions. For each listedversion, the component history includes other information relevant tothe version, such as the version number, the component author, and thedate the version was created.

Relationship tracking window 1230 shows all of the relationships thatinvolve the particular component to be edited. For example, relationshiptracking window 1230, as illustrated in FIG. 12, includes the uniquerelationship number 1232. Each unique relationship number 1232 mayinclude a hyperlink, which provides direct access to view relationshipUI 254 of FIGS. 9A and 9B. In association with each unique relationshipnumber 1232, relationship tracking window 1230 may include informationsimilar to that found in relationship table 752 of FIG. 7 for eachunique relationship number 732. For example, for each uniquerelationship involving the selected component, relationship trackingwindow 1230 may show the mapping between level components. The mappingmay include at least one component from a prior level and at least onecomponent from a subsequent level. For each unique relationship,relationship tracking window 1230 may include the relationship type, thestatus, the proposer, the proposal date, the acceptor, and theacceptance date.

When modifying a component in the editing window 1210, a user has theability to view the relationships that may be affected by a modificationbeing made to the component by, for example, the relationship trackingwindow 1230. This allows an entity to consider the impact an edit orchange to the component would have on other components, other user(s),and the creative process itself.

In addition to being able to edit a component, a component owner mayhave the ability to delete a component. When a component is deleted,system 44 treats the component as if the component were modified and/oredited. For example, system 44 would indicate that the deleted componenthas been ‘touched’ and any relationship involving the component wouldneed to be revalidated.

In one embodiment, when a component is deleted, the component is notnecessarily purged from the system. Instead, the deleted component mayinclude a status and/or flag to indicate that it has been deleted. Inthis case, the deleted component will continue to be viewable in anylogs (e.g., relationship log, component history, and etc.), which aremaintained by system 44. System 44 may be configured to include afeature to hide/unhide deleted components in certain scenarios and/or incertain UIs.

In addition to the UIs discussed above, creative process tracker 220includes a component change detection module 270 (FIG. 2). Componentchange detection module 270 detects any changes, which are made to aprocess instance. For example, component change detection module 270 isable to detect a change in an underlying component. Changes may bereflected by the version number of a component, and tracked by creativeprocess tracker 220. As a result, system 44 is able to provide an entitywith the ability to see the impact of changes at one level in relationto the other levels involved in a process instance, and to be notifiedof these changes.

To illustrate, when a component of a given level is updated, therelationships it may have with components of other levels are consulted.Relationships that are affected are ‘touched,’ which means that theyneed to be revalidated before they can be fully reinstated. Forinstance, as indicated in process instance UI 250 of FIG. 7, this mayresult in a previously “Accepted” relationship becoming a “Proposed(Components Modified).” In some cases, depending upon the nature of therelationships, a change to one level may indirectly affect a number oflevels, and not just the subsequent level.

Creative process tracker 220 includes a recertification notificationmodule 280 (FIG. 2). When changes to the prior level are detected, andrelationships are ‘touched,’ recertification notification module 280 maysend notifications to at least the component proposers indicating thatthe component requirements, and certain relationships (if therelationship still stands) have changed. When changes to the subsequentlevel are detected, and relationships are ‘touched,” recertificationmodule may send notifications to at least the component ownersindicating that they need to reaccept the relationship (if therelationship still stands).

Creative process tracker 220 may include scenario analysis tools 290.Scenario analysis tools 290 are configured in a manner that allows auser to test various scenarios without having to make any lastingchanges to the system. Scenario analysis tools 290 may include a numberof scenario analysis UIs. The scenario analysis UIs may be configured tobe substantially similar to process instance UI 250 of FIG. 7 withrespect to its layout.

In one embodiment, creative process tracker 220 may include a link,which navigates a user to scenario analysis UI. For example, a startscenario button may be included in process instance UI 250. Uponactivating the start scenario button, creative process tracker 220 maydisplay a window (or dialog) that requests the user to enter a name forthe scenario. The scenario name may be used to refer to the scenarioanalysis being performed with respect to the process instance, which wasdisplayed in process instance UI 250. Upon submitting the scenario name,creative process tracker 220 will be in scenario mode. The scenarioname, as well as a scenario mode indicator, may be displayed on thecorresponding scenario analysis UIs. For example, the scenario name andscenario mode indicator may be positioned substantially near the top ofthe scenario analysis UIs. Once in scenario mode, a user may make anycomponent changes (e.g., create a component, modify a component, andetc.) or modify any relationships (e.g., add a relationship, remove arelationship, and etc.) while allowing the user to visualize theconsequences of those actions. Creative process tracker 220 may alsoinclude a stop scenario button. Activating the stop scenario buttonsaves the current scenario for future reference and takes the user backto normal mode.

Scenario analysis tools 290 may include comparison user interfaces thatallow a user to compare and/or contrast a number of different scenariosand/or process instances. In general, the comparison user interfacesallow a user to compare every detail of a scenario and/or processinstance that is selected for comparison. For example, the comparisonuser interfaces may allow a user to compare a scenario with the currentprocess instance, or another scenario. These comparison user interfacesmay further generate and provide any relevant comparison data regardingthe selected process instances and/or selected scenarios. To illustrate,scenario analysis tools 290 may communicate or interact with afunctional module 46 (e.g., project management software) to permit auser to compare the total amount of work (e.g., workload, or workinghours) between a number of selected scenarios and/or selected processinstances.

As discussed, scenario analysis tools 290 allow an entity to experimentwith different scenarios by allowing an entity to change certaincomponents or change certain aspects of components to temporarily to seethe upstream/downstream effects of those changes. For example, an entitymight remove a component from the Business Requirements level to see howmuch of the construct is no longer required. As another example, anentity might remove a single piece of the construct to see whichcomponents and/or relationships of the Business Requirements level areimpacted.

FIG. 13 illustrates a flow diagram associated with defining a process interms of a number of entities (i.e., levels) and a number ofrelationships, which exist between entities in accordance with oneembodiment. In one embodiment, the functionality of the flow diagram ofFIG. 13, and FIG. 14 below, is implemented by software stored in memoryor other computer readable or tangible media, and executed by aprocessor. In other embodiments, the functionality can be performed byhardware (e.g., through the use of an application specific integratedcircuit (“ASIC”), a programmable gate array (“PGA”), a fieldprogrammable gate array (“FGPA”), etc.), or any combination of hardwareand software.

At 1302, it is determined if there has been a request to retrieve anexisting process. If a user does not want to retrieve an existingprocess, then the functionality allows the user to create a process at1306 and/or 1308. If a user would like to retrieve an existing process,then the functionality continues to 1304.

At 1304, the functionality determines the process that the user wants toretrieve, and retrieves it. In some cases, the user might want toretrieve an existing process to finish defining the existing process. Inother cases, the user might want to retrieve an existing process to useit as a template for creating a new process. Whatever the case, once itis determined that an existing process will be retrieved, then thefunctionality retrieves the process and provides it to the user.

At 1306, the functionality receives a number of levels, which define theentities associated with the process. Each level is set up to be definedwith respect to an entity name, and a general role. The functionalityallows the user to define a number of levels. A number of levels may bedefined at any time, as shown in FIG. 13.

At 1308, the functionality receives a number of relationships, whichdefine a known relation or association between entities (i.e., definedlevels). Each relationship is set up to be defined such that anentity/level that sets forth the requirements is connected to theentity/level that is responsible for solving the requirements. Thefunctionality allows the user to define a number of relationships. Anumber of relationships may be defined at any time, as shown in FIG. 13.

At 1310, the functionality receives a process name. The user may providea descriptive label as the process name. If the functionality does notreceive a process name, and the process needs to be saved, then thefunctionality will provide a process name for the process by default. Aprocess name may be designated at any time before the process is saved,as shown in the flow diagram.

At 1312, the functionality saves the process. The process may be savedat predetermined time periods, or upon a user's request to save theprocess.

At 1314, the functionality may receive a request to create a processinstance from a saved process. If a request is not received, then thefunctionality is done. If a request is received, then the functionalitydetermines if the process definition is valid at 1316.

At 1316, the functionality determines if the process is valid. In thiscase, since the process is defined in terms of a process map, thefunctionality determines if the process map is valid. The functionalitymay determine that the process map is valid based on a number ofconditions. For example, these conditions may include determining ifevery entity/level is involved in at least one relationship, anddetermining that every relationship includes an entity, which isconfigured to set requirements, and an entity, which is configured toreceive these requirements and is responsible for providing thesolutions to the requirements.

If the process is not valid, then the functionality proceeds to 1318. Ifthe process is deemed valid, then the functionality proceeds to 1320.

At 1318, upon determining that the process is not valid, thefunctionality sends a notification to the appropriate entities. In manycases, the appropriate entity is the entity or user that created theprocess, or the entity or user that is attempting to create a processinstance from the saved process. The notification indicates that theprocess map is not a valid process. The notification may furtherhighlight why the particular process is not valid, or why a processinstance may not be created based thereupon.

At 1320, the functionality permits a number of process instances to becreated from the defined process. A process instance may include anumber of relationships, which map a solution, proposed by one level, toa requirement, specified by another level.

FIG. 14 is a flow diagram illustrating a process of defining andtracking a solution, proposed by one level, in relation to arequirement, specified by another level, in accordance with oneembodiment.

At 1402, the functionality receives a number of components for a level.

At 1404, the functionality assigns a component number and a versionnumber for every component that it receives at 1402.

At 1406, the functionality receives a number of components for anotherlevel.

At 1408, the functionality assigns a component number and a versionnumber for every component that it receives at 1406.

At 1410, it is determined if a relationship has been received (and/ordefined) with respect to any of the components of a prior level and anyof the components of a subsequent level. The prior level may be thelevel referred to in 1402, and the subsequent level may be the levelreferred to in 1406. Alternatively, the prior level may be the levelreferred to in 1406, and the subsequent level may be the level referredto in 1402.

If a relationship has not been received and/or defined between at leastone component of a prior level and at least one component of asubsequent level, then the functionality continues to check for arelationship between these two levels, or continues to wait for arelationship to be received.

If a relationship has been received and/or defined between at least onecomponent of a prior level and at least one component of a subsequentlevel, then the functionality proceeds to 1412.

At 1412, a relationship number is assigned to the relationship, whichwas defined/proposed at 1410.

At 1414, it is determined if the relationship, which wasproposed/defined at 1410, has been accepted. If the relationship hasbeen accepted, then the functionality proceeds to 1416. If therelationship has not been accepted, then the functionality proceeds to1418.

At 1416, the relationship status for the relationship is updated toindicate that the relationship has been accepted.

At 1418, it is determined if any of the component(s), involved in therelationship, defined at 1410, have been changed. If none of thecomponent(s), involved in the relationship, have been changed, then thefunctionality continues to determine if the relationship has beenaccepted by returning to 1414. If at least one of the component(s),involved in the relationship, have changed, then the functionalityproceeds to 1420, 1422, and 1424. 1420, 1422, and 1424 may be performedin any order, or may be performed simultaneously, as indicated in FIG.14.

At 1420, a new version number is assigned to each component that haschanged.

At 1422, the functionality updates the relationship status, ifnecessary, to indicate that at least one component, involved in therelationship, has been modified. For example, if the relationship waspreviously accepted, then the relationship status changes from an“Accepted” state to a “Proposed (Components Modified)” state.

At 1424, a notification is sent to each appropriate entity. Thenotification informs each entity, which may be affected, about thechange. In many instances, the system may be configured to notify eachcomponent author/owner that is involved in the relationship.

As disclosed, one embodiment includes a system that enables an entity todefine a process. A process may be defined with respect to the entitiesinvolved in a process, and any relationships that may exist between theentities. A number of process instances may be created from the process.Once defined, a given process instance may be tracked. Upon detecting achange to a process instance, system updates any relevant information,and notifies all appropriate entities of each detected change.

System 44 provides entities with the ability to define a process, aswell as the ability to layout each entity's requirements and/orsolutions, while also keeping track of any changes during thedevelopment of the product. System 44 provides an entity with theability to check the status of any requirement and/or solution at anygiven point in time. In addition, system 44 allows entities to view theactual content and/or materials, which are presented as requirementsand/or solutions at any point in time. By providing the above-mentionedfeatures, system 44 is able to ensure that the final solution meets theinitial problem requirements.

Further, system 44 provides impact analysis, making the developmentprocess more agile and allowing the development process to react tochanging customer requirements during a development cycle. System 44 isenabled to provide impact analysis based on a proposed change at anylevel in the solution chain. System 44 allows entities to run variousproposed changes and scenarios on the process before deciding toimplement these changes. For example, during the development of asoftware product, entities, involved in the process, would have theability to imagine what impact removing things from the build would haveon the software product and/or product development process, withouthaving to actually implement these changes. In addition, should anychanges be implemented, system 44 may be set up to automatically notifythe appropriate or relevant entities, which may be affected or which mayneed to be aware of any changes to the overall product, or the productdevelopment process.

System 44 provides entities with the ability to ensure that relateddocuments are synchronized. For example, system 44 is configured toprevent instances in which a solution is not updated based on upstreamand/or downstream changes. In addition, system 44 provides entities withthe ability to prevent instances in which a solution may be signed offat a given time, but changed at a later time without appropriatere-approval.

System 44 allows users to define their own processes, and does not forceusers to use a particular process or change their processes. Forexample, if a number of documents represent the product, then users maycontinue to represent certain aspects of these documents as components,using the system 44.

System 44 provides entities with efficiency gains, by minimizing reworkdue to late discovery of omissions from a solution. System 44 holdsentities, involved in a process, accountable for distinct components ofthe overall product.

System 44 provides entities with the ability to check the progress of aprocess in real-time at any location. This makes it possible formultiple entities to work together in developing a product, but atlocales that are suitable for each entity. Thus, system 44 enablestravel and associated expenses, which typically occur during formalhandoffs and meetings, to be minimized.

Several embodiments are specifically illustrated and/or describedherein. However, it will be appreciated that modifications andvariations of the disclosed embodiments are covered by the aboveteachings and within the purview of the appended claims withoutdeparting from the spirit and intended scope of the invention.

1. A computer readable media having instructions stored thereon that,when executed by a processor, causes the processor to: receive a processdefined in terms of entities involved in the process, and relationshipsamong the entities; determine if the process is valid; permit a firstprocess instance to be created from the process upon deeming that theprocess is valid; and permit the first process instance to be trackedbased at least on requirements and solutions that are specified byentities in the first process instance.
 2. The computer readable mediaof claim 1, wherein the process is determined to be valid upon:determining that each relationship includes a first entity that isconfigured to set requirements and a second entity that is configured topresent solutions that satisfy the requirements; and determining thateach entity is involved in at least one relationship.
 3. The computerreadable media of claim 1, wherein the instructions further cause theprocessor to: permit a second process instance to be created from theprocess upon deeming that the process is valid; and permit the secondprocess instance to be tracked based at least on requirements andsolutions that are specified by entities in the second process instance.4. The computer readable media of claim 3, wherein the instructionsfurther cause the processor to: display a first process name identifyingthe first process instance; display a second process name identifyingthe second process instance; display a first overall status inassociation with the first process name, the first overall statusindicating if every requirement of the first process has been solved;display a second overall status in association with the second processname, the second overall status indicating if every requirement of thesecond process has been solved.
 5. The computer readable media of claim4, wherein the instructions further cause the processor to: provide afirst link in association with the first process name, the first linkproviding access to detailed information regarding selected entities ofthe first process instance; and provide a second link in associationwith the second process name, the second link providing access todetailed information regarding selected entities of the second processinstance.
 6. The computer readable media of claim 5, wherein thedetailed information comprises: a status map to provide an overallstatus of each entity of the selected process instance, the status mapbeing a graphical representation of the defined process; a listing of aset of requirements of the first selected entity and a listing of a setof solutions of the second selected entity; a listing of a set ofcomponent relationships involving the first selected entity and thesecond selected entity, wherein each component relationship indicatesproposed solutions of the second selected level to the requirements ofthe first selected level; a listing of a status of each of the componentrelationships within the set of component relationships; and anindication as to whether each of the component relationships within theset of component relationships have been approved, wherein an approvaldate is provided in association with each approved componentrelationship.
 7. The computer readable media of claim 5, wherein uponreceiving a change to the first process instance, the instructionsfurther cause the processor to: update the first overall status upondetermining that the first overall status is not reflective of the firstprocess instance including the change; and update the detailedinformation to reflect the change to the first process instance.
 8. Thecomputer readable media of claim 7, wherein the instructions furthercause the processor to: send a notification to each entity affected bythe change, the notification includes information regarding the change,and any updates to the detailed information resulting from the change tothe first process instance.
 9. The computer readable media of claim 5,wherein upon receiving a change to the second process instance, theinstructions further cause the processor to: update the second overallstatus upon determining that the second overall status is not reflectiveof the second process instance including the change; update the detailedinformation to reflect the change to the second process instance. 10.The computer readable media of claim 9, wherein the instructions furthercause the processor to: send a notification to each entity affected bythe change, the notification includes information regarding the change,and any updates resulting from the change to the second processinstance.
 11. The computer readable media of claim 6, wherein theinstructions further cause the processor to: receive a scenarioinvolving a temporary change to at least one component of the firstprocess instance; preview the first overall status to reflect the firstprocess instance in view of the temporary change to a component; previewthe detailed information to reflect the temporary change to the firstprocess instance; and permit the first overall status and the detailedinformation to revert to a state prior to receiving the scenario uponreceiving a request.
 12. A collaborative system for developing aproduct, the system comprising: a process map user interface thatenables a process for developing the product to be defined in terms ofmultiple entities, wherein the multiple entities include a first entitythat is responsible for providing at least one component requirement toa second entity, wherein the second entity is responsible for providingat least one component solution to the first entity; component userinterfaces that enable each entity to create, modify, and trackcomponent requirements and/or component solutions associated with aprocess instance of the process; a process instance user interface thatenables the second entity to review the at least one componentrequirement of the first entity and propose the at least one componentsolution to the first entity, the process instance user interfaceenables the first entity to review the at least one component solutionof the second entity and accept the at least one component solution inresponse to the at least one component requirement; and a componentchange detection module that detects changes to the at least onecomponent requirement and the at least one component solution of theprocess instance, wherein the first and second entities are notified ofany detected changes.
 13. The system of claim 12, further comprising: ascenario analysis user interface that enables the first and secondentities, respectively, to visualize effects of various changes toeither the component requirement or the component solution that isexpected to occur to the process instance without having to actuallyimplement the various changes to the process instance.
 14. A computerimplemented method for tracking a process for developing a product, saidmethod comprising: storing a process map, the process map defines aprocess with respect to multiple levels, each level includes an entitythat is responsible for creating a number of component requirementsand/or a number of component solutions for another level; and tracking astatus of each component requirement and/or solution at any specifiedpoint in time; updating the status in accordance with any changes thatare made to any of the component requirements and/or solutions; andnotifying any relevant entities, which are affected by a change to thecomponent requirement and/or the component solution, upon detecting thechange to a component requirement and/or component solution.
 15. Acomputer implemented method for tracking a process for developing aproduct, said method comprising: receiving at least one componentrequirement from a first entity; receiving at least one componentsolution from a second entity; receiving a proposed relationship betweenthe at least one component requirement and the at least one componentsolution; and displaying an acceptance timestamp and acceptor inassociation with the proposed relationship upon determining that theproposed relationship has been accepted.
 16. The computer implementedmethod of claim 15, the method further comprising: determining if thereare any changes to the component requirement; determining if there areany changes to the component solution; updating a status of the proposedrelationship to reflect if a change has been detected upon detecting achange to at least one of the component requirement and the componentsolution.
 17. The computer implemented method of claim 16, the methodfurther comprising: sending notifications to the first entity and thesecond entity upon detecting a change to at least one of the componentrequirement and the component solution.
 18. The computer implementedmethod of claim 15, the method further comprising: assigning a uniquecomponent number to each received component requirement and eachreceived component solution; assigning a version number in associationwith the unique component number assigned to each received componentrequirement and each received component solution; assigning new versionnumbers to component requirements or component solutions when acomponent requirement or a component solution is modified; anddetermining that a change to a component has occurred when the newversion number is assigned, and sending notifications to the first andsecond entities based, in part, upon the change to the component. 19.The computer implemented method of claim 15, the method furthercomprising: displaying contents of the component requirement, thecontents include a description of a technical requirement associatedwith developing the product; displaying contents of the componentsolution, the contents include a technological implementation of thetechnical requirement.